It's not unique.

I didn't choose that name.

I chose to complain about it.

This is an implementation that meets the RFC spec. If you want to complain about semantics, you'll have to complain to the IETF.

Not challenging the spec. But I am saying that this is not suited for anything in Arma.

Arma can only do floats, so in use cases where you can potentially exceed 2^23 IDs, UUIDs would be useful. The chance of a collision is ridiculously low and way less of a risk than running out of numbers.

There is no need to do this when everyone already has a unique client id.

Okay, and that helps how exactly?

Those are unique and therefore useful. I see no use case for this.

Now you have one unique ID per client. What if I need 2^24 unique IDs per client? Say, for example, PFH IDs?

What if I need 2^24 unique IDs per client?

I would use a function that actually provides unique ids, so not this one.

Well, then provide a better one. The generated UUIDs are more than good enough, but feel free to prove me wrong. However I'm not willing to wait a hundred years for you to generate a duplicate.

CBA as a general library can and should provide those if there is any use for it

What is the use case? Providing unique ids is not one of them.

Providing an ID that is unique within the next 100 years.

You can use https://community.bistudio.com/wiki/systemTimeUTC to make it mooooooooost likely unique, down to the millisecond.

The OS time is by default not that accurate, but sure, let's say it is.

The chances of a duplicate UUID are far lower than those of a duplicate timestamp. Imagine assigning a unique ID to every player on a server. If that code is executed at the same time for every client, the chances of an overlap are probably higher than 1/1000. Consider that this code might be executed many times, not just per day, but across multiple servers and for every session. You're going to have duplicates.

Merge it @BaerMitUmlaut!

I lack the rights to merge.